Processing of electronic transactions

ABSTRACT

Systems  100 ; devices  110, 120, 130, 150, 160 ; methods  2400, 2500 ; and machine-executable programming structures stored in persistent (i.e., non-transitory), computer-readable media  604, 606, 618, 126, 139  for the rapid and secure negotiation, authorization, execution, and confirmation of multi-party data processes, including payment transactions conducted between purchasers  190  having electronic access to bank accounts and other sources of payment, merchants operating e- and/or m-commerce transaction systems  132, 134, 136 , and banks and other financial institutions  120  capable of electronically communicating with both.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation application of U.S. patentapplication Ser. No. 15/648,942, filed 13 Jul. 2017. U.S. patentapplication Ser. No. 15/648,942 claims all right and benefit, includingpriority, of U.S. Provisional Patent Application No. 62/361,919, filed13 Jul. 2016 and entitled “SECURE PROCESSING OF ELECTRONIC PAYMENTS”,and is a continuation-in-part of U.S. patent application Ser. No.15/000,685, filed 19 Jan. 2016 and entitled “SECURE PROCESSING OFELECTRONIC PAYMENTS”, and a continuation-in-part of U.S. patentapplication Ser. No. 15/201,428, filed 2 Jul. 2016 and entitled “SECUREPROCESSING OF ELECTRONIC PAYMENTS,” and claims all right and benefitthereof, including rights of priority of U.S. Provisional PatentApplication No. 62/188,067, filed Jul. 2, 2015, and entitled “SECUREPROCESSING OF ELECTRONIC PAYMENTS”; U.S. Provisional Application No.62/200,859, filed Aug. 4, 2015, and entitled “SECURE PROCESSING OFELECTRONIC PAYMENTS”. The entire contents of each of the foregoing areincorporated herein by this reference.

DISCLAIMER

Aspects of the material disclosed in this application relate to thecreation, administration, manipulation, processing, and storage of datauseful in processing of payment transactions. Aspects of such creation,administration, manipulation, processing, and storage may be subject toregulation by governmental and other agencies. The disclosure herein ismade solely in terms of the use of logical and physical components,functions, and combinations in signal processing systems andcommunications systems, in order open new economic and communicationspossibilities, without regard to statutory, regulatory, or other legalconsiderations. Nothing herein is intended as a statement orrepresentation that any of the systems, components, or processesproposed or discussed herein, or the application thereof, does or doesnot comply with any statute, law, regulation, or other legal requirementin any jurisdiction.

TECHNICAL FIELD

The present disclosure relates generally to the generation and secureand efficient execution of electronic signal exchanges, and moreparticularly to improved systems, methods, and programming structuresfor the secure negotiation, authorization, execution, and confirmationof multi-party and multi-device transactional data processes.

BACKGROUND

Electronic signal exchanges such as those representing payments andother transactions are a type of electronic signal exchange that haveprovided significant benefits to human kind, including improvedefficiency in the distribution and production of goods and services. Inaddition to numerous benefits, however, such transactions are associatedwith both numerous risks and intense pressures from users of suchsystems for speed, security, reliability, and convenience. Although manydifferent systems, devices, and processes useful in negotiating andexecuting such transactions have been proposed, there remainssignificant room for improvement.

In many cases, for example, users of desktop computers, smart phones andother mobile digital assistants, and other network communication devicesencounter difficulties in safely, efficiently, reliably, andconveniently effecting purchase transactions with merchants by means ofbrowser-based, point-of-sale (POS), m-commerce, and other forms ofe-commerce systems, particularly where such users have access, or areentitled to have access, to multiple sources of funds to be applied inpayment for such transaction. For example, a given merchant might noteasily and reliably support payments through the use of accountsadministered by one or another bank, and vice versa; difficulties areencountered by networked merchant resources in setting up and enablingaccess to rewards, loyalties, and other forms of marketing processes;and banks and other financial institutions are hampered in, or unableto, pass along efficiencies in data and signal management andadministration to purchasers, merchants, and other parties involved inelectronic transaction.

In addition, merchants and other providers of goods and services,including for example governmental and not-for-profit organizations,seldom have rapid, efficient, and reliable means for having input totransactional flow, when banks or other financial institutions controlaccess to bank accounts and other sources of payment funding.

In general, rapid, reliable, and efficient communication betweenfinancial institutions and merchants have not always been available.

SUMMARY

In various aspects and embodiments the disclosure herein providessystems, devices, methods, and machine-executable programming structuresstored in persistent (i.e., non-transitory), computer-readable media forthe secure execution of electronic signal exchanges, and moreparticularly improved systems, methods, and programming structures forthe rapid and secure negotiation, authorization, execution, andconfirmation of multi-party data processes, including paymenttransactions conducted between purchasers having electronic access tobank accounts and other sources of payment, merchants operating e-and/or m-commerce transaction options, and banks and other financialinstitutions capable of electronically communicating with both. Invarious embodiments, the disclosure provides systems, methods, andprogramming structures which are particularly well suited for thenegotiation, authorization, execution, and confirmation of suchpurchases, and other electronic resource (including funds) transfers.

For example, in one aspect the disclosure provides networked paymentauthorization management systems, and related processes and logicalprogramming structures. A system according to such aspect of theinvention can comprise one or more network communication systems, one ordata processors, and one or more persistent memory devices. Thepersistent memory device(s) comprise stored, machine-interpretableinstructions adapted to cause the data processor(s) to receive frompurchaser communication devices, using the network communicationsystems, requests for generation of select merchant payment tokens. Inresponse to the requests, and subject to any applicable legal,regulatory, and/or business constraints, the payment authorizationmanagement systems can generate the select merchant payment tokens, andstore them in secure memory, along with identifiers associated with oneor more transaction funding sources, such as credit, debit, and rewardsaccounts associated with requesting purchasers. In addition, the selectmerchant payment tokens can be stored in association with specialtransactional requests submitted by the select merchants, such asrequests for application of discounts, modified loyalty or rewardsprogram rules, rebates, etc. In some embodiments, such special merchanttransaction requests can be updated at any time, at the request of theselect merchant(s).

In another aspect, the disclosure provides networked merchanttransaction management systems, and related processes and logicalprogramming structures. A system according to such aspect of theinvention can comprise one or more network communication systems, one ordata processors, and one or more persistent memory devices. Thepersistent memory device(s) comprise stored, machine-interpretableinstructions adapted to cause the data processor(s) to receive frompurchaser communication devices, using the one or more networkcommunication systems, select merchant payment token authorizationrequests, such requests comprising secure purchaser identifiers andselect merchant payment token generated by payment authorizationmanagement systems associated with the purchasers. The systems cancommunicate with the payment authorization management systems in orderto confirm the validity of the tokens and any associated conditions,restrictions, or rules, including any special transactional requestsprovide by the merchant transaction management systems.

In a further aspect, the invention provides purchaser communicationdevices, and related processes and logical programming structures. Adevice according to such aspect of the invention can comprise one ormore network and/or short-range data communication systems, one or moredata processors, one or more of any of a wide variety of input, output,and/or input-output devices, and one or more persistent memory devicecomprising stored, machine-interpretable instruction sets. Suchmachine-interpretable instruction sets can multiple distinct applicationprograms, i.e., logical structures adapted to enable the dataprocessor(s) to execute separately-controllable processes according todistinct security and logical specifications. For example, suchapplication programs can include internet and other web browsers, andspecialized payment management applications (e.g. virtual wallets)associated with banks or other financial institutions, and with merchante- and/or m-commerce platforms. By enabling users of such purchaserdevices to operate such payment management applications and merchantapplications separately, but in cooperative fashion as taught herein,the invention enables purchasers to set up payment and other preferenceswith both the FIs that administer their payment accounts and themerchants from whom they wish to acquire goods and/or services, whileallowing both the FIs and merchants to maintain their distinct securityand legal obligations while operating according to their own preferredcommercial standards. Such merchant and FI applications enable merchantsand FIs to communicate with purchasers in ways that are efficient andconvenient for the purchasers, while allowing the merchants and FIs tomaintain their own security and commercial standards, through the use ofcontrolled encryption, secure memory storage and access, etc.

In all cases, select merchant tokens generated and otherwise processedin accordance with the disclosure can be used to complete electronictransactions in accordance with any special requests generated bypurchasers and/or merchants, using accounts identified by purchasers assources of payments, rapidly, securely, and efficiently.

Thus, the use of systems, devices, and methods in accordance with thedisclosure offers a number of advantages, including more convenient orless burdensome user interfaces, particularly with respect to theability to draw on multiple sources of transaction funds and/or otherpayment sources, which can be held, administered and/or otherwisecontrolled by single or multiple financial institutions and/or otherfinancial services providers, and increased ability on the part ofpurchasers, merchants, and FIs to complete transactions, which in somecircumstances may be critical to their physical and/or economic healthor well-being. In addition, various aspects and embodiments of theinvention enable more flexible and efficient interactions betweenpurchasers, merchants, and account administration systems such asservers controlled by banks, credit unions, and other financialinstitutions (FIs).

Many further advantages will be apparent to those skilled in therelevant arts from the disclosure herein.

Those skilled in the relevant arts will appreciate, once they have beenmade familiar with this disclosure, that the use of the invention inconjunction with other improvements provided by the applicant opens avery wide variety of further capabilities and advantages. For example,applicant's trusted platform, universal wallet, split pay, and real-timecredit systems and processes, as described in co-pending, co-owned U.S.patent application Ser. Nos. 15/000,685 and 15/201,428, (each of whichhas been incorporated herein by reference) can be leveraged efficiently,with advantageous results.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will be made herein to the accompanying drawings, in which:

FIG. 1 is a schematic block diagram of an example system suitable foruse in processing data in accordance with aspects of the disclosure;

FIG. 2 is a schematic block diagram of an example signal communicationdevice suitable for use in processing data in accordance with aspects ofthe disclosure;

FIGS. 3 and 4 are schematic diagrams showing representative signalexchanges between components of systems for secure processing ofelectronic transactions in accordance with aspects of the disclosure;and

FIGS. 5-9 show embodiments of graphical user interfaces suitable for useby various embodiments of purchaser devices in implementing variousaspects and embodiments of the invention.

For clarity and ease of description, like reference numerals are be usedin the drawings to describe the same or like parts.

DETAILED DESCRIPTION

Reference is initially made to FIG. 1 , which shows a schematic diagramof a system 100 suitable for use in implementing various aspects andembodiments of the invention. In the example shown, a system 100includes one or more purchaser or other user request communicationdevices 110 (also a “network transaction communication device” and/or a“network communication device”), for use by purchasers or other users190 (FIGS. 3, 4 ); one or more payment authorization management systems120; one or more merchant transaction management systems 130, each ofwhich can comprise, for example, one or more merchant point of sale(POS) and/or other transaction device(s) 132, 134, and merchant or otherfinancial service provider (FSP) server(s) 136; one or more optional4^(th) party transaction processors 150; and optional further FIsystem(s) 160, as described below. System(s) 100 may also include, or beadapted to communicate with or by means of, one or more communicationsnetworks 200 such as the internet, public or private wireline networkssuch as the PSTN, etc.

While only one of each of devices 110, 120, 130, 132, 134, 136, 150, 200is shown in FIG. 1 , those skilled in the relevant arts will readilyunderstand that a system 100 can include any desired, required, orotherwise advantageous numbers of such devices.

Payment authorization management system(s) and other FSP, FI, ortransaction processing system(s) or platform(s) 120, 136, 150, 160 maycomprise or consist of any suitably-configured enterprise, server,desktop, laptop, or other suitably-configured types or class(es) ofelectronic data processing (computer) systems. A large number andvariety of suitable devices are now available commercially, anddoubtless others will be developed subsequent to the preparation of thisspecification. Further details of platform(s) 120, 150, 160 are providedbelow. As will be understood by those skilled in the relevant arts, oncethey have been made familiar with this disclosure, such systems caninclude any one or more of a wide variety of data/signal processingunits 122 and memories 126, in order for example to securely, reliably,rapidly, and efficiently store, access, and read stored datarepresenting account information for any desired numbers of accountusers, as well machine-readable instructions representing logicalstructures to be applied in authorizing, evaluating, adjudicating, andotherwise process requests relating to purchases and other transactions.Such components can include one or more of each of processor(s) 122,network and other data communications systems 124, and memories 126,which can include any persistent and secure memory(ies) suitable for usein implementing the various systems, devices and processes disclosedherein.

Merchant transaction management system(s) 130 and device(s) 132, 134,136 may comprise or consist of any suitably-configured POS, mPOS, andbackend data processing devices, including special-purpose devicesincluding, card, chip, short-range wireless, and other devices, servers,etc. as well as server-class general-purpose systems such as thosedescribed above in connection with payment authorization managementsystem(s) 120. As will be understood by those skilled in the relevantarts, once they have been made familiar with this disclosure, suchsystems can include any one or more of a wide variety of data/signalprocessing units and memories, in order for example to securely,reliably, rapidly, and efficiently store, access, and read stored datarepresenting account information for any desired numbers of accountusers, as well machine-readable instructions representing logicalstructures to be applied in authorizing, evaluating, adjudicating, andotherwise process requests relating to purchases and other transactions.Such components can include one or more of each of processor(s) 137,network and other data communications systems 138, and memories 139,which can include any persistent and secure memory(ies) suitable for usein implementing the various systems, devices and processes disclosedherein. Further details of merchant system(s) 130 and device(s) 132,134, 136 are provided below.

Any of devices 110, 120, 130, 132, 134, 136, 150, 160 may communicatewith each other by wireless (including radio, wireless telephone,optical, RFID, and infrared), wireline, or other means, using forexample suitably-configured signal processors, transmitters, andreceivers configured to communicate via the internet, the PSTN, and/orother communications networks 200, using any suitable protocols orcombinations of protocols. Very commonly, such devices incorporate oneor more dedicated communication subsystems, operating under the controlof one or more central processing units (CPUs) and/or other processors,for such purposes.

Referring now to FIG. 2 , there is shown a schematic representation of apurchaser communication device 110, in the form of a mobilecommunication device such as a smart phone, tablet, or other PDA. Aspreviously noted, a device 110 may generally be any portable, desktop,or other electronic signal/data processing and communication devicecomprising an assembly of electronic, structural and/orelectro-mechanical components within a suitable housing, and which insome embodiments provides a user with various voice and/or datafunctions including short and/or long-range network connectivity. Aswill be understood, terms such as “portable” or “mobile”, when usedherein, can indicate that device 110 may generally be transportedbetween different physical locations by a user without resort tophysical aids. In particular, in various embodiments mobile embodimentsof devices 110 can include devices that may be carried on a user'sperson or clothing, such as cellular or other radio telephones, personaldata assistants (PDA), tablets, notepads, portable computers, smartwatches or jewelry, and the like. However, various aspects andembodiments of the invention may be implemented using non-mobilecommunication devices 110 such as laptop or personal computers.

In any such embodiments, purchaser communication device(s) 110, 600 mayinclude one or more data processors (CPUs) 602, random access or otherforms of persistent, typically re-writable memory(ies) 604, 606 any ofwhich may store non-transient either or both of data and machineinterpretable instruction sets representing logical structures in theform of device applications, or other programs or routines. In general,CPU(s) 602 can include any microprocessor(s) or other general or specialpurpose processing unit(s) configured to control the overall operationof device(s) 110 and their various components, with which CPU(s) 602 maybe connected by a bus(es) or other electronic link(s) or path(s) adaptedfor transferring data or other signals, power, etc., on the device 110.Read and write operations of CPU(s) 602 may be facilitated bymemory(ies) 604, 606 or other integrated circuit(s) or volatile memorystorage associated with or integrated within CPU(s) 602 or to whichCPU(s) 602 have access.

Memory(ies) 604, 606 may include one or more persistent (i.e.,non-transitory) memory stores, such as flash memory or read-only memory(ROM), which are either physically embedded within the device(s) 110 orwhich may alternatively be removably loaded or inserted into device(s)110 by a user, such as on a subscriber identity module (SIM) card orsecure digital (SD) memory card. Memory(ies) 606 may be used to storeany type of data and/or executable machine instruction files, such asbut not limited to media files (music and photos), as well as softwareused to implement operating systems (OSs) 608 and other programs,routines, or applications, as described herein. Memory(ies) 606 may alsobe used to store one or more files used by CPU 602 or mobile OS 608 toexecute different functions or control different components on mobiledevice 110, 600, such as contact information, network preferences,application data, and other files.

Purchaser communication device(s) 110 may further be equipped with oneor more of any of a very wide variety of input and/or output components610, in order to enable user to interactions with the device(s) 110.Such components, which are generally denoted herein as 610, may provideboth for the user to input data or commands into device 110, as well asto perceive or otherwise access data or information output by the device110. Without limitation, different possible input components 610 caninclude touch pads, dials, click wheels, touchscreens and otherdisplays, keyboards, keypads, and other buttons and switches, as well ascameras, microphones, and biometric sensors (e.g., fingerprintscanners). Example output components 610 can include speakers, screensand visual displays, rumble packs, and combinations thereof. Other I/Ocomponents 610 not specifically mentioned herein may also be included indifferent embodiments.

Device(s) 110 can further include data communications systems, includingfor example long-range or network communications components 612 and/orshort-range network communications components 614 to enable thedevice(s) 110 to employ a variety of voice, data, and other signalcommunication functions. As will be appreciated, the terms “long-range”and “short-range” may be used herein to denote relative distances andare not intended to denote any specific limitations or ranges. Thus,long-data communications systems 612, 614 allow device(s) 110 tocommunicate with other proximately or remotely located targets, whichcan be other similarly or differently configured devices 110, servers120, 130, 150, 160, systems 100, and other network-enabled devices.

For example, long-range or network communications component(s) 612 maybe used by a device 110 to communicate with other components ofsystem(s) 100 via cellular or other distributed networks 200 usingsuitable voice and/or data communications protocols, such as but notlimited to Time Division Multiple Access (TDMA), Code Division MultipleAccess (CDMA), Global System for Mobile Communication (GSM), WirelessApplication Protocol (WAP), and others. Using such protocols a device110 can route communications to arbitrarily remote devices of varioustypes, including voice, data, and text-based messages withoutlimitation. To enable long-range communications, various hardware and/orsoftware components may be included in system(s) 612, such as anantennae, transmitters, receivers, and digital signal processors.Specific configuration(s) of long-range communications systems 612 candepend generally upon the communication protocol(s) that are implementedand the purposes to which a device 110 is to be put.

Short-range or near-field communications component(s) 614 can enablecommunication between mobile or other device(s) 110 and other relativelyproximately located devices, servers, or systems. For example,short-range communications 614 may include one or more short-rangetransceivers, such as for connection to Wi-Fi (802.11 standard) orBluetooth networks, as well as other modes of short-range communication,like RFID, infrared or optical. In some embodiments, short-rangecommunications 614 may in particular include a near field communications(NFC) subsystem 616 that may be utilized to communicate with an NFCreader, among various different purposes or functions, so as to initiatecontactless mobile payments with merchant POS terminals 134 as describedfurther below.

In various embodiments devices 110 further include secure elements 618configured as tamper-resistant, limited-access storage environments forsensitive data and other information, such as payment credentials orcryptographic keys, data and programming structures. For example, secureelement(s) 618 may include or operate under the separate and securecontrol of any or all of suitably-configured integrated circuit(s)(IC(s)), an operating system(s) (OS(s)), or program(s), includingpayment management (or “virtual wallet”) application(s) 112, merchanttransaction management application(s) 114, host card emulation (HCE)applications and the like. Secure element(s) 618 may be either embedded(integrated) physically within a mobile device 110 or, alternatively,provided on a card such as a SIM or SD card that is insertable into thedevice 110. CPU(s) 602, applications 112, 114, and NFC subsystem(s) 616may in various embodiments have access to the contents of secure element616.

Device(s) 110 can further include power supply(ies) 620 configured withany components or circuitry that are suitable for generating, receivingor transmitting power to CPU 602 and other components of a device 110.For example, a power supply 620 may include circuitry for processingpower received from an external power source, such as an electricalutility or grid, when a device 110 is plugged into or otherwiseconnected to such external power source. In some cases, power supply 620may further include one or more batteries, such as nickel metal hydride,nickel cadmium, and lithium-ion batteries, which may provide a source ofpower when device 110 is not able to connect to an external powersource. Other power generating or processing circuitry, such as solarpanels or inductive coils, may also be included so that power supply 620may deliver energy to different components within a device 110. Itshould be noted that individual connections between power supply 620 andother components within device 110 are not shown in FIG. 6 and insteadpower supply 620 is indicated for convenience only as an isolatedelement.

As previously mentioned, in many embodiments purchaser and other requestcommunication device(s) 110 are not “mobile” device(s). Thus, forexample, a purchaser device 110 may have a size, shape and/or weightthat make it difficult, inconvenient, or otherwise impractical for auser to transport over more than trivial distances without some physicalassistance or assistance, or for routine portable use. In particular, anon-mobile user device 110 may be one that a user cannot practicallycarry on their person or clothing. Examples of a non-mobile device 110include a user's desktop computer and other normally stationary devices.

Non-mobile embodiments of device(s) 110 according to the invention mayor may not differ, in terms of communications ability, secure memory,etc., from mobile embodiments. In some cases, for example, a non-mobileembodiment of a device 110 may lack a secure element 618 because suchdevice 110 is not configured to receive a SIM or SD card. In otherscases, at least one of long-range communications 612 and short-rangecommunications 614 may differ between mobile and non-mobile embodiments.For example, instead of long-range communications system(s) 612configured for wireless communication over distance, a purchaser device110 can include one or more modems or other network components forconnecting to a distributed network 200, such as the Internet, in placeof a cellular antenna. In some cases, short-range communications 614 maynot include an NFC receiver 616, but may include WI-FI and/or Bluetoothantennae or others. Embodiments of the systems and processes describedherein may utilize either a mobile device 600 or a non-mobile devicewithout limitation.

As further shown in FIG. 2 and described below, a mobile or other device110 can in accordance with various aspects and embodiments of theinvention be configured to initiate and otherwise control mobilepayments and other electronic transactions from within either or both ofpayment management or “virtual wallet” application(s) 112 associatedwith one or more banks or other FIs responsible for administration ofmonetary and alternative value (e.g., loyalty or rewards) accounts andmerchant transaction management application(s) or program(s) 114provided by or otherwise associated with a merchant or merchant system130 or, as described further below, from non-dedicated application(s) orprogram(s), such as one or more web browsers or merchant transactione-commerce websites administered by, for example, a merchant transactionmanagement system 136.

As will be understood by those skilled in the relevant arts, and as willbe explained more fully below, an “application,” or application program,is a set of computer-interpretable instructions adapted to be executedby one or more processors 602, 137, 122 of device 110, 120, 130, etc.,in accordance with logical structures directed toward a common task orpurpose, such as the management of one or more banking or otherfinancial or value accounts (e.g., application 112), for interactionwith a specific merchant e- or m-commerce program (application 114),etc. Instructions associated with such applications can be storedtogether in single memory(ies) 606, 604, 126, 139, etc., or can bestored in multiple memories served by or otherwise accessible to devices110, 120, 130, using distributed programming techniques.

Accordingly, one or more different merchant and payment managementtransaction communication applications 112, 114 or other programs may beinstalled by a user of a device 110 into mobile or other device memories606, 604, for execution by a CPU 602 under the higher-level control ofan operating system (OS) not shown. Only one such merchant application114 and one payment management application (such as a virtual wallet)each are shown in FIG. 2 for convenience, but any number may beinstalled in different embodiments according to the user's preferences.

Among other possible functions, a virtual wallet or other paymentmanagement application 112 can comprise data representingmachine-executable instruction sets representing rules or other logicalstructures to be applied by one or more processor(s) 602 of a device 110and configured to enable a user of the device to interact with accountand/or transaction management and control programs implemented orotherwise controlled by one or more payment authorization managementsystems 120 and adapted to enable secure access to operating systems andother programs that will enable an authorized user of a device 110 toaccess and control information pertaining one or more monetary or othervalue accounts, so as to control deposits, withdrawals, change of name,address, and other information, etc. As will be understood by thoseskilled in the relevant arts, such applications 112 may reside wholly ona device 110 and be configured for secure communication with accountaccess and control programs implemented on such systems 120, inaccordance with logical structures residing in memory on the user device110; or such applications 112 can be configured for distributedimplementation by, for example, providing a front end/user interfaceapplication on the user's device 110, with control and managementprocessing taking place in accordance with logical structures associatedwith the application residing on the FI system 120.

A merchant application 114 can comprise data representingmachine-executable instruction sets representing rules or other logicalstructures to be applied by one or more processor(s) 602 of a device 110and configured to enable a user of the device to purchase a product orservice that a merchant 130 displays or advertises to the user fromwithin the merchant application 114, or to navigate to a website orother e- or m-commerce site associated with the merchant and browseservices, products, etc., and set up and execute purchase or othertransactions. Different possible merchant applications 114 can includethose which are dedicated to a specific merchant's goods and/orservices, as well as third party applications, such as auction sites ormerchant group affiliations, which offer goods and/or services on behalfof multiple merchants. Applications 114 can reside wholly on a user'sdevice 110 and be configured for secure communication with transactioncontrol programs implemented on merchant transaction management systems130, in accordance with logical structures residing in memory on theuser device 110; or such applications 114 can be configured fordistributed implementation by, for example, providing a front end/userinterface application on the user's device 110, with transaction controlprocessing taking place in accordance with logical structures associatedwith the application residing on the merchant system 130.

In some embodiments, as described further below, a merchant transactionmanagement application 114 may be configured so that payment credentialsor other information stored within one or more wallet applications 112may be pulled, or otherwise accessed, by the merchant application 114from or through a virtual wallet application 112 or (other) securememory source without need for a user of a device 110 to open or launchany separate wallet or other payment management application 112. Forexample, when a payment transaction is initiated by a user via amerchant application 114 the user may be presented with a screen orprompt providing the user with a choice which payment credential storedin any of one or more wallet applications 112 to pull for use inexecuting the transaction. Alternatively, merchant application 114, 630may automatically pull a default or pre-selected payment credential fromwallet application 112, 622 without prompting the user.

The provision of separate merchant transaction management application(s)114 and FI-related payment management application(s) 112 on a purchaserdevice 110 can enable a purchaser or other user to interact withmerchant system(s) 130 and FI(s) 120 separately, using logicalstructures generated by the respective merchants and FIs and therebyensuring that communications involved in such interactions are conductedaccording to distinct security, legal, and commercial standards requiredor otherwise imposed by the merchants and FIs.

By enabling cooperative use of such applications 112, 114 as disclosedherein, the invention opens up significant new transactionalpossibilities, without sacrificing security or commercial advantage ornecessity.

In the same and further embodiments, memory(ies) 604, 608 of a device110 can further incorporate or otherwise support non-merchant specificapplications or programs, such as games, general purpose web browsers,readers, and the like from which it may be possible to initiateelectronic transactions by, for example accessing a merchant websiteover the internet, via pop-up (graphical) user interfaces (GUIs,) etc.Such non-merchant applications may be coupled to one or more mobilewallet applications 112 in order to retrieve payment tokens or othercredentials that may be stored therein, or otherwise cooperate with suchwallet applications; and, via CPU 602, to a network communicationcomponent such as short-range communications 614 or long-rangecommunication 612 or to any other network component, such as a modeminstalled in a non-mobile user device 110, 110′, and thereby any one ormore merchant transaction management system(s) 130.

For example, in such cases a user may, to initiate an electronictransaction, navigate to a web page or website using, e.g., anyavailable I/O devices as described herein. After the user has generateda suitably-configured transaction request data set (or ‘requestedtransaction data set’), comprising for example data representing one ormore items the user wishes to purchase, and perhaps a full or partialdescription thereof, along with item, subtotal, and/or total purchaseprices, by for example selecting the items for addition to the merchantapplication's virtual shopping cart, and has initiated a payment (e.g.,‘checkout’) process, merchant application 112 may display an option tothe user to pay for the transaction using a wallet application 112installed in memory 606 and/or secure element 618. Alternatively, thepayment tokens selected for use in the transaction may be located in orother memory or locations on mobile device 110 or, in some cases, invirtual wallet(s) 112 or other memory(ies) or application(s) in a securecloud resource hosted by or otherwise associated with one or more FIsystems 120, 160. When the user selects to pay by wallet application 112the device operating system may interface with such application 112 soas to obtain a suitable payment token depending on the selected form ofpayment. The obtained payment token may be transmitted over short-rangecommunications 614 or long-range communication 612 for processing by amerchant transaction management backend system 130. Alternatively, auser may securely log in to a bank account administered by an FI system120, 160 from within an application or program on user device 110 usingsome form of identification information (e.g., user identification andpassword, biometric, etc.) and, once authenticated, the user's bank maytransmit electronic payment tokens to the merchant/acquirer forprocessing of the transaction. Processing of the electronic paymentthrough a payment network or other entities may then proceed asdescribed herein.

Thus, for example, in various aspects and embodiments the inventionprovides systems, processes, and persistently stored, machine-accessibleand machine-readable programming structures that enable one or morerequest devices 110, such as smart phones, tablet computers, wearabledevices, or other mobile devices, to interact with payment authorizationmanagement system(s) 120 by means of suitably-configured signalexchanges over a communications network 200, and, as a result of suchinteractions, to be cause to be generated or otherwise be provided witha secure data set, such as a token representing account information, forstorage in volatile or non-volatile memory 604, 606, 618 of the device110 and thereby enable a user to conduct transaction(s) with one or moremerchant system(s) 130.

As will be appreciated by those skilled in the relevant arts, anypurchaser or request device(s) 110 may be associated with multipleauthorized human and/or juristic users, and/or with multiple accountsassociated with such user(s). For example, each such device may be usedby different authorized users and/or entities in differentjurisdictions, or in different data processing contexts, as for exampledifferent social media platforms vs inside a brick-and-mortar merchantpremises or particular online services (e.g., an online music or mediasource). A representation of, link to, and/or other data orinstruction(s) associated with each validated identity may be stored insecure memory controlled by or otherwise associated with any offapplications 112, 114, etc.

A further advantage offered by various aspects and embodiments of theinvention is improvement in the manner in which single or multiple formsand sources of payment to be used in completing a transaction can beagreed upon in advance, at the time of a transaction, and/or after thetransaction has been confirmed, between a user of a device 110 and amerchant system 130, and communicated to the bank/FI processor 120, 160,for example, by the POS 132, 134, or server 136, etc. Such methods ofpayment may be registered with or otherwise authenticated by the bank160 or other trusted platform 120, in the form of select merchantpayment token data sets (or “authorized merchant token data sets)described herein, so that the need for transmitting and interpretinginformation identifying such methods may be obviated or otherwisereduced. In this manner, for example, payment may be completed with useof an instruction to the bank 160 or other trusted platform 120 toprocess payment according to the agreed upon method of payment, withouthaving to provide any details (which may be of a sensitive nature)related to the selected source or method of payment in the paymentmessage itself.

Alternatively, such forms of payment may be negotiated between a user ofa device 110 and one or more payment management authorization systems orother FIs 120, in accordance with logical structures associated witheither or both of applications 112, 114, as described herein. Amongother advantages, such configurations enable merchants 136 to takedirect or indirect part in negotiating the form of such of suchpayments, and special rules, or business functions, such as promotions,special loyalty offers, etc., to be applied in conjunction with suchtransactions.

Thus a wide variety of improved and advantageous types and modes ofpayment settlement processing are enabled by the invention.

For example, at the time of a transaction, both the user of a device 110and a merchant system 130 may agree one or more types, modes, orprotocols of payment(s) to be used (e.g. credit, debit, cash banktransfer, loyalty point redemption, including one or more specificaccounts associated with each such type of payment), and identifier(s)associated with the selected protocol can be transmitted to the trustedplatform server 120.

In such cases, when a user initiates a purchase or other transactionwith a merchant system 130, as for example through the use of thePSTN/Internet and a desktop merchant application, a variety of dataand/or other signals, including for example transaction confirmationsignals, may be generated by any or all of systems 120, 160, 130, andpassed to the user's device 110. For example, when a purchase or othertransaction request is generated

Examples of ways in which the invention may be used to increaseflexibility and convenience for purchasers and other users 190,merchants 130, and FIs 120, etc., in setting up preferences for andconducting payments and other electronic transactions are described inconnection with in FIGS. 3 and 4 . In particular, means for enablingeither or both of a user 190 and merchant system 130 to designate types,protocols, rules, and/or specific accounts to be used for receiving,accepting, and otherwise processing payments are described. For example,as shown and explained in connection with FIG. 3 , a purchaser or otheruser 190 of a network request communication device 110 is enabled toselect one or more desired funding sources to be associated withpayments made via a merchant transaction application 114 or otherwise inconnection with purchases made through one or more specific vendors,while the merchant 130 is enabled to specify one or more preferredpayment types, protocols, formats, and rules to be used in receiving orotherwise processing payment from the user 190 through the merchantapplication 114, independent of any preferences designated by the user190.

This can be accomplished efficiently through use of the systems andmethods disclosed herein because, for example, as previously noted andas illustrated in the example embodiments shown in FIGS. 1, 3 and 4 ,merchant application(s) 114 installed on a purchaser communicationdevice 110 can be adapted for communication with a variety of componentsof system(s) 100, including for example any or all of virtual walletapplication(s) 112, merchant backend system(s) 130, 136, and paymentauthorization management systems and/or other FI system(s) 120, 150,160, etc.

In the example shown in FIG. 3 , for example, at 2402 a user 190 caninvoke or otherwise access a merchant application 114 and, through theuse of suitably-configured user interfaces (UIs), generate a preferredfunding source instruction request data set representing one or morefunding sources to be used in transactions conducted with the merchant,or through the application 114, and route the preferred funding sourceinstruction data set to the merchant application 114.

For example, as shown in FIG. 5 , a user 190 of a purchasercommunication device 110 comprising one or more input/out devices 610such as one or more touchscreens 621, select switches 623, cameras 625,microphones 627, and speakers 629 can invoke one of a virtual walletapplication 112, merchant application 114, or a network browser byselecting one of corresponding application icons 112′, 114′, 116′.

In the example shown in FIGS. 3 and 6 , a user 190 has selected a “MYSTORE” application icon 114′ to invoke a merchant transactioncommunication application 114 associated with a merchant “MY STORE” andadapted to facilitate secure and efficient communications between thedevice 110 and merchant server 136 of a merchant transaction managementsystem 130 as shown in FIG. 1 . In the example shown in FIG. 6 ,invocation of the application 114 has enabled the user 190 to access a“Preferences” GUI 639 adapted to solicit designation by the user of oneor more accounts to be used, for example as defaults, as sources offunds for satisfaction of one or more purchase transactions conductedwith the merchant MY STORE's transaction management system 130, eitherdirectly or through the “MY STORE” application 114.

As previously noted, a purchaser communication device 110 can beprovided with multiple merchant applications 114 as well as one or morevirtual wallet applications 112, each of which can be configured tofacilitate communications an individual bank or other FI accountadministration system 120 directly. Alternatively a single virtualwallet application 112 can act as a one-stop clearing house byfacilitating communications with multiple FI systems 120. Merchantapplications 114 can be configured to facilitate communications with anyone or more account administration systems 120 directly, or in manyembodiments to communicate with designated systems 120 through walletapplication(s) 112, optionally at the election or designation of one ormore users authorized to access the device 110. In the example shown inFIG. 6 , the merchant application 114 GUI 639 has generated icons 631 toenable the user 190 to designate one or more payment accountsadministered by or otherwise associated with a first preferred bank orother FI 120; 633 to enable the user to designate one or more accountsadministered or otherwise associated with a second preferred bank orother FI 120; and 634 to enable a user to access a listing of accountsassociated with multiple FIs 120. In each case, in the example shown,the merchant application 114 is configured to communicate with thecorresponding FIs 120 indirectly, by communicating with virtual walletapplication(s) 112 controlled by the user 190's device 110.

In accordance with logical structures associated with the application114, selection of an item 634 “ALL MY CARDS” can one or more ofprocessors 602 to generate and present a GUI such as GUI 640, andthereby enable a user 190 to designate one or more accounts associatedwith multiple FI systems 120 to be used as funding sources in connectionwith transaction(s) to be conducted with the merchant MY STORE'stransaction management system 130. In the example shown in FIG. 7 ,selection of a command item 631 “My Preferred Cards” can enable the user190 to designate one or more accounts associated with a preferred bankor FI 120; selection of a command item 633 “My Preferred Cards atanother Bank” can enable the user 190 to designate one or more accountsassociated with a second bank; and selection of a command item 634 “AllMy Cards” can enable the user 190 to designate one or more accountsassociated with any or all of multiple FIs 120.

As shown for example in FIG. 7 , at 2404-2408 selection by the user 190of a command item 634 “All My Cards” can result in generation of a GUI640 listing multiple accounts administered or otherwise associated withmultiple FI systems 120. For example, invocation of the command item 634can cause one or more processors 602 of the device 100 to generate, inaccordance with instructions incorporated within logical structuresassociated with the My Store merchant API 114, a preferred or selectpayment or funding source instruction request data set (also referred toas a “request to add card” data set), and route the data set either to asingle wallet application 112 configured to control access to accountsadministered by multiple FI systems 120; or to multiple dedicated walletapplications 112, each configured to control access to accountsadministered by a single FI system 120; or to multiple FI systems 120directly, without working through any wallet application 112. At eachstep in processes 2400, 2500, data can be accessed from memory,generated, and routed to various recipients in accordance with securitymeasures imposed by logical structures associated the application(s)114, 112, handling the data; and therefore designated by theirrespective merchant 130 and FI 120 sponsors or producers. Thus thesecurity needs of all parties can be respected, in varying combinations.

The example to follow will be described in terms of the firstpossibility. In such a case a “request to add card” command data setgenerated by a merchant API 114 and routed to a multi-FI walletapplication can, for example, include:

-   -   <secure merchant application identifier><flag indicating nature        of request>        where:    -   <secure merchant application identifier>=identifier(s)        representing local resource address associated with the        requesting application 114; and    -   <flag indicating nature of request>=identifier(s) representing a        request by an authorized user of the device 110 for data        representing a list of accounts available for use by the        requesting user in transactions conducted with the merchant(s)        associated with the requesting merchant API 114

Among the significant advantages offered by such aspects of theinvention is the enablement of merchants and/or merchant associationsassociated with API(s) 114 to have increased input to and control oftransactions conducted with specific purchasers, or classes ofpurchasers, and/or transactions involving accounts controlled orotherwise administered by specific banks or FIs associated with paymentauthorization management system(s) 120. For example, at various pointsin the processes described below, the merchant is enabled to cause,through the use of suitably configured rules implemented by logicalstructures stored in data associated with an API 114, any of a widevariety of data communications routed to FI system(s) 120 to includedata representing requests for special processing of such transactions.In such instances, request to add card data sets can, for example,include:

-   -   <secure merchant application identifier>    -   <merchant special processing request flag(s)>        where:    -   <merchant special processing request flag(s)>=identifier(s)        representing one or more requests, including special merchant        transaction processing requests, for special processing of        transaction and/or other processes conducted between the        requesting user 190 and/or device 110, merchant 130 associated        with the application 114, and FI(s) associated with accounts to        be specified in response to the with the request to add card        data set.

Such merchant special processing request flags can include anyidentifiers, representing any processing requests, that can beunderstood and appropriately processed by merchant system(s) 130, FIsystem(s) 120, and optionally by either or both of user(s) 190 anddevice(s) 110. Examples of such processing requests include applicationof merchant, FI, and/or user specified rules pertaining to any of thefollowing:

-   -   Application of special loyalty point awards (e.g., twice nominal        points to be awarded, based on value of transaction and/or        specific goods and/or services involved therewith    -   Special discount programs offered to preferred customers only    -   Rebate programs, and special parameters associated therewith,        including e.g., preferred rates for specific purchasers or        classes of purchaser, based on transaction history,        demographics, etc.    -   Identifiers indicating FI(s)/FI system(s) 120 that a merchant or        merchant 130 does or does not prefer to deal with, or will or        will not transact with    -   Merchant account-type preferences (e.g., merchant prefers to        deal only with any one or more credit, debit, loyalty accounts,        or types of accounts etc.)    -   Special tracking of demographic and other data associated with        transactions, and requests for transactions, and sharing of        collected data with merchants and/or purchasers    -   Generation of one or more pre-paid tokens, at specifically        identified values    -   Generation of non pre-paid tokens, with transaction value limits        or caps

Optionally, identifiers associated with such special merchant or othertransaction processing requests can be communicated implicitly, based oneither or both of the secure merchant application identifier(s) and theflag indicating the nature of the request. For example, pluralities ofeither merchant identifiers and/or flags can be used, a singleidentifier or flag indicating both the identity of the requestingmerchant, or the fact that an account listing is requested, and thenature of a special processing request.

Among further options, the merchant special or other transactionprocessing request flag(s) can also represent or include either (a) oneor more specific, one-time requested transaction amount(s); or (b)express or implied request(s) for authorized limit(s) for a single ormultiple transactions. For example, as described further below, eitheror both of a user 190 and merchant 130 can request generation of one ormore pre-paid, negotiable payment token data sets, and/or a limit to begenerally authorized for future transactions, subject to verification ofavailability of funds at the time of a proposed transaction.

As will be understood by those skilled in the relevant arts, once theyhave been made familiar with this disclosure, enabling merchantsassociated with systems 130 to make such requests opens possibilitiesfor new and potentially more efficient ways of conducting electronictransactions, with savings that can be shared among any or all ofmerchants, purchasers, and FIs.

Having received such a preferred funding source instruction request (or“request to add card”) data set, at 2404 the merchant application 114 orvirtual wallet application 112 can, in accordance with rules representedby logical structures associated with the application, generate one ormore preferred funding source identification request data sets (or“eligible accounts list request data sets”) adapted to cause polling ofone or more FI systems 120 associated with accounts or other fundingsources controlled by or otherwise available to the user 190 insatisfying payment transaction requests for data identifying all or somesuch available funding sources.

For example, on receipt of the “request to add card” command data set, avirtual wallet application 112 associated with a specific bank can parsethe data set and, using flags or other identifiers as described above,execute known table look-up and value comparison techniques to determinerouting information for the one or more FI systems 120 to which therequest is to be routed, subject to any merchant preferences for fundingFIs expressed by means of explicit or implicit special processingrequest identifiers. Identifiers associated with any such specialprocessing requests suitable for consideration by target FI system(s)120 can also be explicitly or implicitly included in the eligibleaccounts list request data set.

Eligible accounts list request data sets generated in accordance withsuch aspects of the invention can, for example, be formatted inaccordance with any agreed or otherwise suitable protocol(s) and caninclude:

-   -   <address(es) of secure FI portals><return address identifier(s)>        -   <flag(s) identifying request for accounts information>            -   <secure user identifier/verification data>                -   <(optional) merchant identifier(s)>    -   <(optional) special merchant processing request identifier(s)>        where:    -   <address(es) of secure FI portals>=network resource addresses        for any or all of FI systems 120 to which the request is to be        routed. Where, for example, multiple FI systems 120 are to be        polled for eligible accounts, multiple preferred funding source        identification request data sets can be generated, and        independently routed.        where:    -   <return address identifier(s)>=network resource address(es) to        which responsive data is to be routed (e.g, a URL or other        network identifier associated with the requesting device 110    -   <flag(s) identifying request for accounts        information>=identifier(s) useable by recipient FI system(s) 120        for identifying the received data string as a request for an        account listing    -   <secure user identifier/verification data>=secure identifier(s)        associated with authorized users or other access to accounts to        be identified. Can include any suitable characters or symbols,        including names, passwords, biometric data, and pointers to any        such data stored on FI recipient systems 120, etc.    -   <(optional) merchant identifier(s)>=in cases where the        identity(ies) of merchants associated with the request are not        implicit in the request, or otherwise apparent, one or more        identifiers associated with merchants and/or merchant systems        130 can be included. Can include names, codes, symbols, or any        other suitable identifiers    -   <(optional) special merchant transaction processing request        identifier(s)>=flag(s) or other identifiers associated with        special merchant transaction processing requests associated with        the information request

At 2406, such a request can, for example, be forwarded by a virtualwallet application 112 (or merchant application 114) installed on theuser 190's device 110 to the one or more FI system(s) associated withthe virtual wallet application 112. For example, logical structuresassociated with the application 112 (or merchant application 114) cancause one or more of processor(s) 302 to route the preferred fundingsource identification request data set(s) to a network or short-rangecommunication system 612, 612 to route the request to one or morepayment authorization management systems 112 via network(s) 200 or NFCor other communications paths.

On receipt, any payment management authorization system(s) 120 to whicha preferred funding source identification request data set has beenrouted can parse the request, and based on any agreed or otherwiseaccepted protocols and use of table look-up or other suitable processesor techniques determine the identities of requesting purchasers or users190, merchants identified by the request, and special preferences orrules to be applied to identification of eligible accounts, and applysuch criteria to identification of any eligible accounts. For example,each account associated with an authorized purchaser can be polled, andcompared to received criteria, and an eligible account data list can beassembled, for example by writing associated identifiers to one or morebuffers or other temporary memory stores. In addition to criteriaidentified above, logical structures associated with paymentauthorization management systems 120 and/or processes executed therebycan be used to set or enforce account eligibility requirements, whichcan for example include any applicable legal requirements, bank rules(e.g., available credit, availability of debit funds and applicabilityof any daily or other periodic withdrawal limits, line of credit (LOC)restrictions, foreign currency exchange restrictions, etc.);requirements or restrictions imposed by merchants associated with therequest; requirements or restrictions imposed by the FI on specificmerchants or classes of merchants; agreements with merchants or merchantassociations, etc. Subject to any such restrictions, eligible accountscan include any source(s) of funds available to the identified user,including any and all forms of demand and other deposit accounts,certificates, etc.; credit accounts, including LOCs; loyalty/rewardspoints accounts; foreign currency accounts, etc.

If any optional special merchant or other transaction processingrequests have been included by a requesting merchant or user have beenidentified, the list of eligible accounts can be determined using thoseas criteria as well.

Thus, once the requesting user has been suitably identified and verifiedas authorized to access one or more funding sources associated with oneor more FI systems 120, at 2406 the virtual wallet application 112 (ormerchant application 114) can communicate with the FI(s) 120 to requestgeneration of a data set representing a list of accounts available fordesignation as preferred funding sources with respect to transactionsconducted through the merchant application 114, and at 2407 one or moreprocessors associated with the polled FI system(s) 2407 can return, viaone or more network communications systems, eligible account list dataset(s) that include the following:

-   -   <originating (user return) network address>    -   <flag identifying account list data set><account identifier(s)>        where:    -   <originating (user return) network address>=network resource        locator(s) to which the eligible account list data set(s) are to        be returned    -   <flag identifying account list data set>=identifier(s) useable        by recipient application (s) 112 (or 114) for identifying the        received data string as a requested list of eligible accounts    -   <account identifier(s)>=identifier(s) suitable for use by        requesting application(s) 112, 114 in generating GUI(s) suitable        for use by a requesting user 190 of one or more accounts to be        used in conducting transaction(s) with the specified merchants

Such data sets can also include, if/as desired, identifiers associatedwith merchants with whom the accounts are eligible to be used, and/ordata representing information confirming or otherwise related to anymerchant or user special processing requests.

At 2408, the virtual wallet application 112 (or merchant application114) to which and eligible account list data set(s) has been returnedcan use the data received at 2407 to cause generation and display on theuser's device 110 of a GUI 640 listing the eligible funding source(s)for selection as preferred funding source(s). This can accomplished bydisplaying such a GUI directly through use of logical structuresassociated with the virtual wallet application 112, or by returning thelist data to the requesting merchant application 114 so that logicalstructures associated with the merchant application 114 can be used togenerate and display the preferred funding source selection GUI.

Thus, as previously noted and as shown for example in FIG. 7 , at 2408selection by a user 190 2402 of a command item 634 “All My Cards” canresult in generation of a GUI 640 listing multiple accounts administeredor otherwise associated with one or more FI systems 120. In the exampleshown in FIG. 7 , GUI 640 lists accounts controlled or otherwiseadministered by a plurality of payment authorization management systems120 “My Bank” and “My Other Bank.” Listing 641 includes checking,savings, credit, LOC, merchant loyalty, bank loyalty, and 3^(rd) partyrewards accounts administered by or available through My Bank, as wellas checking, credit, and rewards accounts administered by My Other Bank.

Accounts such as third-party rewards accounts (such as that listed underMy Bank) which are not directly administered by a FI 120 by whom anaccount listing has been generated can for example be accounts linked toa bank, or to a merchant, or to a purchaser, by agreements between anyor all of the bank, merchant and purchaser. For example, a merchantassociated with a merchant API 114, with respect to whom a user 190wishes to designate one or more accounts to as sources of funds fortransactions conducted with the merchant, can identify special rewardsrules by means of one or more special merchant processing requestidentifier(s), as described above, and thereby authorize or cause an FIsystem 120 generating an eligible account listing to include the thirdparty rewards account in the listing.

A GUI listing eligible accounts can include one or more radio buttonitems 643 or other GUI devices in association with each account, inorder to enable the user 190 to select one or more accounts as preferredfunding sources for transactions with the specified merchant(s).

An important feature enabled by such aspects and embodiments of theinvention is the ability to identify multiple accounts as preferredfunding sources for transactions. For example, split pay features suchas those described below, and in the incorporated priority applications,can be applied. Thus, in the example shown in FIG. 7 , user 190 canselect any desired number of the displayed accounts by touching thecorresponding radio button item(s)

When multiple accounts have been selected, the user can be provided witha choice of establishing a priority list, with first choices beingexhausted before secondary or tertiary choices are used to satisfytransaction payments. For example, the merchant or wallet application112, 114 can generate a GUI which enables the user to use a physical orvirtual keyboard to identify a desired precedence, or the order in whichselections are designated can be used to establish the desiredprecedence.

If, alternatively, the user wishes to apply split pay techniques, theuser can select a split pay option item 645 to invoke GUIs adapted forprecedences, ratios, etc., to be used in split pay processes, forexample as described in the incorporated references.

If a listing 641 of eligible accounts is too long to be displayedconveniently on a single GUI screen, the user can use a “NEXT” commanditem 647 to access a continued list.

When the user is satisfied with his/her selections, he/she can select acommand item 649 “NEXT,” “DONE,” “SEND,” etc., and at 2410 the virtualwallet application 112 or merchant application 114 can route a selectionof one or more preferred funding sources selected by the user 190 inresponse to the list displayed at 2408 to the FI(s) 120 by which theyare controlled or otherwise administered, along with data implicitly orexplicitly representing an instruction or request for generation of apreferred funding source token based on the user's selection.

For example, in accordance with logical structures associated with theapplication 112, 114 which generated the GUI 640, the application 112,114 can generate a merchant token authorization request data set, or“select merchant payment token request data set,” and route it to thepayment authorization management system(s) 120 intended to processtransactions conducted between the user 190 or device 110 and merchantsystem(s) 130. Such a select merchant payment token request data setcan, for example, include data representing:

-   -   <address of secure FI portal><originating (user return) network        address>        -   <flag identifying request for token authorization>    -   <secure user identifier/verification data><selected merchant        identifier(s)>        -   <selected payment account identifiers>            where:    -   <address of secure FI portal>=network resource locator        associated with responsible payment authorization management        system 120    -   <originating (user return) network address>=network resource        locator(s) to which confirmations and/or other communications        are to be returned    -   <flag identifying request for token authorization>=identifier(s)        useable by recipient system 120 for identifying the received        data string as a request for a secure payment authorization        token associated with preferred transaction payment accounts to        be used with identified merchant(s)    -   <secure user identifier/verification data>=data representing        token(s) or other credential(s) securely establishing authority        of the requesting user to access accounts identified in the        request    -   <selected merchant identifier(s)>=data representing information        suitable for routing transaction payment(s) to the intended        merchant recipient, or recipient account(s), or other        identifier(s) associated with selected merchants    -   <selected payment account identifiers>=data representing user        accounts designated at 2408 as sources of transaction payment(s)

At 2412, the corresponding FI system(s) 120 can create preferred fundingsource token(s) and link or otherwise associate the token(s) with theselected funding sources. This can be done, for example, by a primarybanking/account administration processor 120 or by an associated orindependent token service processor 160, as shown in FIG. 1 . Generationof such tokens can be subject to adjudication by the receiving FIsystem(s) 120, for example to ensure that requesting user(s) 190,prospective authorized merchants 130, and/or combinations of the two,are not subject to legal, FI, or other restrictions in conductingtransactions.

For example, a secure token generation service 120, 160 associated withthe FI system 120 responsible for managing accounts accessible by therequesting user can generate and store in secure persistent memory, suchas a suitably secure database of select merchant payment token datasets, an unpredictable select merchant payment token (or “selectedmerchant payment token”) to serve as a unique identifier of (i) themerchant(s) or merchant account(s) to which payments associated with useof the token are to be made; and (ii) the accounts to be used as fundingsources for transactions between the merchant(s) and the requestinguser. The token can also be linked, e.g., through a table-look upprocess, with any special business functions or requests associated withthe token request, including for example any special loyalty accountrules, discounts, etc., specified or requested by the correspondingmerchants, users, or FI(s) 120.

Any suitably coded or otherwise non-predictable character set(s) (e.g.,random or pseudo-random string(s) of letters, numbers, specialcharacters, etc.) or other credentials can be used as an authorized orselected merchant payment token generated at this step.

Among the many advantageous features offered by various aspects andembodiments of systems and processes in accordance with the invention isthe ability of banks and other payment authorization management systems120 to generate and maintain tables or other databases or data sets ofselect merchant payment token data sets, for use in adjudicating,authorizing and otherwise processing transaction requests received fromdevices 110 on behalf of purchasers and other requesting users 190. Aswill be apparent to those skilled in the relevant arts upon a reading ofthis disclosure, by enabling each of the requesting user 190, FI system120, and merchant 130 to specify special requirements or requests,including choices of payment accounts, discounts and other specialoffers or rules, etc., to be applied in processing such transactions—toindividual purchasers or groups or classes of purchasers—the inventionopens up a very wide range of new possibilities inelectronically-enabled commerce, with the ability to rapidly andefficiently modify transactional processes at any time.

For example, an authorized or select merchant payment token data setgenerated by a payment authorization management system 120 in accordancewith this aspect of the invention can include multiple data records,each including some or all of the following, along with any otherrequired or desired data:

-   -   <non-predictable authorized token><identifiers associated with        account(s) to be used as transaction funding        sources><identifier(s) associated with requesting merchant        and/or accounts to be credited in transaction(s)><flag(s)        identifying merchant transaction processing requests or other        special business function rules>        -   <(optional) pre-authorized transaction limit(s)>            where:    -   <non-predictable select merchant payment token>=a select        merchant payment token comprising any suitably non-predictable        character set(s) (e.g., random or pseudo-random string(s) of        letters, numbers, special characters, etc.) or other credentials        uniquely associated with the merchant(s) associated with the        request and accounts to be used as sources of payment funds    -   <identifiers associated with account(s) to be used as        transaction funding sources>=data representing identifier(s)        suitable identifying account(s) to be used a funding sources to        satisfy payments in transactions conducted between the        requesting user 190/device 110 and merchant(s) identified in        association with the token request    -   <identifier(s) associated with requesting merchant and/or        accounts to be credited in transaction(s)>=data representing        account number(s) or other routing information suitable for use        in routing transaction payments to merchants identified in        association with the token request    -   <flag(s) identifying merchant transaction processing or other        special transaction processing requests>=flags or other data        representing or referring to special transaction processing        requests to be applied in processing of transactions associated        with the select merchant payment token. Requests can originate        from corresponding merchant(s) 130, purchaser or other        authorized account users 190, or account administration FIs 120,        and subject to any applicable laws, rules, or agreements, can be        changed at any time subsequent to creation of the select        merchant payment token    -   <(optional) pre-authorized transaction limit(s)=any        pre-authorized transaction limits imposed by requesting user(s)        190, merchant(s) 130, or FIs 120

As explained further below, on receipt from an authorized user 190and/or device 110 of a transaction request data set comprising datarepresenting an authorized merchant payment token, a paymentauthorization management system 120 controlling such a data set can usethe select or authorized merchant payment token to look up an associatedselect merchant payment token data set, identify applicable parties andrules, and apply them to adjudication and other processing of thetransaction request.

Optional pre-authorized transaction limits can be included where, forexample, a pre-paid token is to be generated and stored on a user'sdevice 110, or within secure memory at an account administration FI 120,for later access by the user in transactions with the merchant. In suchcases funds can be set aside in a temporary or permanent sequestered or‘buffered’ account until expended in a transaction.

In other cases, generation of the Merchant API token can be created inadvance simply in order to speed transaction processing at the time atransaction is desired, while uniquely identifying all applicablepayment rules, including special discounts, loyalty rewards, andaccounts to be used as transaction funding sources. In such cases, atthe time of transaction the normal processes of verifying availabilityof sufficient funds to settle a transaction, etc., can be applied.

At 2414, the preferred funding source token, or select merchant paymenttoken, can be returned by the FI system 120 that generated it to therequesting wallet application 112 or merchant application 114, which at2416 can forward it, or a modified or replacement token, to merchantapplication 114 associated with the token request process 2400.

For example, at 2416 the select merchant payment token can be routed byan account management system FI 120 to the requesting user 190's virtualwallet application 112, and at forwarded by wallet application 112 to amerchant application 114 associated with the authorized merchant, whichat 2418 can in turn forward the token to the corresponding merchantback-end system 130.

Thus, for example, at 2418 a merchant application 114 can generate aselect merchant token confirmation data set, comprising datarepresenting one or more secure purchaser identifiers associated withthe prospective purchaser 190 and/or device 110 and the same or anotherselect merchant payment token, and route the select merchant tokenconfirmation data set to a merchant transaction management system 130,in order enable the merchant backend system 130, 136 associated with themerchant application 114 to store the select merchant token andoptionally the secure purchaser identifiers in secure persistent storageand optionally to request generation of a special payment token to beused by the merchant application 114, 630 in internal or otherprocessing transaction payment requests originated by the user's device110. The select merchant token and secure purchaser identifier(s) can beused by the merchant transaction management system 130, for example, toconfirm the validity of proposed transactions and to route inquiries,confirmations, transaction receipt data, etc. to one or more userdevices 110, and to route confirmations, inquiries, and other requiredor desired information to payment authorization management system(s) 120as appropriate or otherwise suitable for negotiating, executing,confirming, and clearing transactions.

In addition, at 2420, the merchant back-end system can route the tokento banking/token management services associated with FI system(s) 120,160 a request for confirmation, with identifiers representing anyspecial transaction processing requests, and/or for generation of aseparate unpredictable identifier to be associated by the merchantsystem 130 with the user 190 in processing of any transactions initiatedby the user, etc. Such a select merchant token confirmation request dataset can include, for example:

-   -   <select merchant network address/merchant identifier(s)>    -   <flag indicating nature of request><select merchant payment        token>    -   <merchant account identifier(s)><flag(s) identifying (updated)        transaction processing requests><(optional) pre-authorized        transaction limit(s)>        where:    -   <select merchant network address/merchant identifier(s)>=network        resource locator(s) to which confirmations and/or other        communications are to be returned to the select merchant        back-end system 130    -   <flag indicating nature of request>=data interpretable by the        receiving FI system 120 to indicate any specific nature of the        request, and type(s) of data to be expected in subsequent data        fields    -   <select merchant payment token>=select merchant payment token        generated at 2412, or suitable proxy    -   <merchant account identifier(s)>=any required or desired        identifiers associated with merchant accounts to be used in        transaction processing, where for example required or desired in        conjunction with the specific request identified above    -   <flag(s) identifying (updated) transaction processing        requests>=flags or other data representing or referring to        special merchant transaction processing requests to be applied        in processing of transactions associated with the select        merchant payment token or updates thereto, requested by merchant        system 130. In addition to loyalty program, discounts, and other        requests to be applied to transactions initiated by the user 190        or device 110 associated with the merchant token generating        request, such merchant-initiated special processing requests can        include preferred payment protocol(s) to be applied to        communications respecting transactions conducted with the        merchant system 130    -   <(optional) pre-authorized transaction limit(s)>=if not included        in updated special processing request, new or updated limits to        be associated with transactions requested by user 190 or device        110 associated with the select merchant payment token

As important advantage offered by this aspect of the invention is thatselect merchant token confirmation request data sets can be generatedand routed by merchant transaction processing systems 130 step 2420 orany subsequent time, in order for example to revise, delete, replace orotherwise modify one or more merchant transaction processing requests,so that, for example discounts on various specified goods and/orservices can be increased or decreased, rewards or loyalty program rulesrevised, etc.

For example, by including in such select merchant token confirmationrequest data sets data representing one or more purchasers 190, awardsprograms, discounts, etc., applicable to one or more persons, or classesof persons, can be created, replaced, removed, or otherwise modified, bycausing one or more payment authorization management system systems 120to update pluralities of authorized merchant token data sets and/orselect merchant data sets.

As a further example, at 2420 the merchant backend system 130, 136 cangenerate and forward to the FI system 120 associated with the preferredfunding source(s)/merchant token request the same or another merchantapplication payment token request data set. An important advantageoffered by this aspect of the invention is that the merchant applicationpayment token request data set or merchant confirmation data set caninclude data representing a request that payments made between therequesting user 190, device 110, and/or merchant application 114 beformatted in accordance with an desired type or protocol, independent ofthe preferred funding source(s) designated by the user 190. For example,if the user 190 has requested that transactions initiated through themerchant application 11 be funded using one or more debit and/or pointsaccounts, as described above, the merchant system 130 can request thatpayments drawn from such accounts be processed in accordance with EMV(Europay-Visa-MasterCard) and/or other credit protocols. As will beapparent to those skilled in the relevant arts, the invention enablesthe user 190 and merchant 130 to independently designate one or morepreferred funding source types and protocols to be used in processingtransactions between the user's merchant application 114 and therequesting user 190.

At 2422, the responsible FI 120 can return a suitably-formatted selectmerchant payment token, or confirmation of an earlier-generated token,to the requesting merchant backend system 130 for use as describedherein. Such confirmation can further include, for example, datarepresenting confirmation or proposed modification(s) of specialtransaction processing requests forwarded (directly or indirectly) bythe authorized merchant system 130. Thus, for example, in variousaspects and embodiments payment authorization management systems 120 canbe configured to parse data representing merchant transaction processingrequests and cause the corresponding requests to be reviewed forcompliance with legal, regulatory, and FI policies, optionallyautomatically according to suitably-configured heuristic analyses, or byhuman regulatory and/or policy compliance officers; and, when requestedmodifications are approved, cause the associated FI system(s) 120 togenerate and route to requesting merchant transaction managementsystem(s) 130 suitably-configured merchant transaction processingrequest confirmation data set(s) comprising flags or other datarepresenting confirmation of acceptance by a payment authorizationmanagement system of one or more merchant transaction processingrequests.

For example, at 2422 in response to receipt of a select merchant tokenconfirmation request, a responsible FI system 120 can update its dataset associated with the authorized merchant token, and return the sameor another suitable token to the Merchant back end. The confirmation caninclude any data representing confirmation of any special merchant-sidespecial function requests, such as special savings, rewards pointsoffers, etc.

Thus for example a token confirmation data set returned by an FI 120 toa requesting merchant backend system 130 can include:

-   -   <merchant network address/merchant identifier(s)>    -   <flag indicating nature of confirmation><select merchant payment        token>    -   <user/purchaser identifier(s)><flag(s) identifying special        transaction processing requests><(optional) pre-authorized        transaction limit(s)>        as explained above.

As one example, in accordance with the examples described above, such amerchant application payment token or other select merchant paymenttoken can be provided in a form suitable for processing using“conventional” payment rails 150 through, for example, use of adiscretionary field in a “conventional” transaction payment data set.For example, using the example described above, an select merchantpayment token can comprise a plurality of encoded or otherwiseunpredictable data sets or items, formatted as follows:

-   -   <token type><issuing FI><currency><value><time stamp>        -   <issuer ref><discretionary data>

Where:

-   -   <token type>=format associated with the payment token, e.g. a        credit token (EMV, etc.), debit token, etc. designated by the        merchant system 130 at 2420 in FIG. 24    -   <issuing FI>=identifier(s) associated with the FI 120 that        issued the token    -   <currency>=US dollars, Canadian dollars, Yen, etc. to be        associated with value(s) represented by the token    -   <value>=amount of currency of specified type payable by the        issuing FI on presentation of a pre-paid token, or a transaction        limit associated with a reusable or other token to be presented        with a transaction verified at the time of purchase    -   <time stamp>=date/time of token creation; optionally useful also        for determining expiration of token after given length of time,        etc.    -   <issuer ref>=token reference number generated by the issuing FI,        can be tied, for example, to a specific transaction and/or user        account. Etc.    -   <discretionary data>=select merchant payment token as described        above, thus data representing the funding source(s) designated        by the user 190 at 2408

In such cases, as a process of parsing all received transaction datastrings, an FI 120 can parse a received transaction request data setassociated with an select merchant payment token, and can look up theassociated select merchant payment token data set to process thetransaction according to specified special transaction requests, asdescribed above.

As noted above, through generation and processing of suitably-formattedselect merchant payment token data sets, the invention can be used toenable the use of multiple funding sources to be applied toward thesatisfaction of purchase transactions. In various embodiments, suchpayments can be processed through the use of conventional ‘paymentrails’ provided by third-party FI system(s) 150, by generatingtransaction request data sets comprising select merchant payment tokensin discretionary data fields of EMV and/or other traditional paymentprotocols.

For example, such use of select merchant payment tokens can be used tofacilitate payments made according to Applicant's unique split-paytechniques. As one example, an select merchant payment token received byan FI 120 in a discretionary field of a transaction request formattedaccording to the EMV protocol can be used to look a correspondingauthorized merchant data set. The authorized merchant data setassociated with the select merchant payment token can include asplit-pay data set comprising the following bits:

<SN/S1/P1/S2/P2/SX/PX>

Where:

SN=number of funding sources represented

S1=first funding source identifier

P1=percentage or amount of value to be funded by source 1

S2=second funding source identifier

P2=percentage or amount of value to be funded by source 2

SX=X^(th) funding source identifier

PX=percentage or amount of value to be funded by source X

It may be seen by the foregoing that in various aspects and embodimentsthe invention provides networked payment authorization managementsystems 120, wherein such a system comprises one or more networkcommunication systems 124, one or more data processors 122, and one ormore persistent memory devices 126, the at least one persistent memorydevice 126 comprising stored, machine-interpretable instructions adaptedto cause the at least one data processor to receive from a purchasercommunication device 110, using the at least one network communicationsystem 124, a select merchant payment token request data set, the selectmerchant payment token request data set comprising data representing atleast one or more selected merchant identifiers and one or more selectedpayment source identifiers; to generate a secure select merchant paymenttoken; generate an authorized merchant token data set comprising atleast the select merchant payment token, the one or more selectedmerchant identifiers, and the one or more payment source identifiers;cause the authorized merchant token data set to be stored in any or allof secure persistent memories 126, 139, 606, 604; using the same oranother network communication system 124, route the authorized merchanttoken data set to the same or another purchaser communication device110; and receive from a merchant transaction management system 130,using the same or another network communication device 124, a selectmerchant token confirmation request, the select merchant tokenconfirmation request comprising data representing at least the selectmerchant payment token.

In the same and further aspects and embodiments, the invention providesnetworked merchant transaction management systems 130, wherein such asystem comprises one or more network communication systems 138, one ormore data processors 137; and one or more persistent memory devices 139,the at least one persistent memory device 139 comprising stored,machine-interpretable instructions adapted to cause the at least onedata processor 137 to receive from a purchaser communication device 110,using the at least one network communication system 138, a selectmerchant payment token authorization request data set, the selectmerchant payment token authorization request data set comprising datarepresenting at least one or more secure purchaser identifiers and aselect merchant payment token; generate a select merchant tokenconfirmation request data set, the select merchant the select merchanttoken confirmation request data set comprising data representing atleast the select merchant payment token, and optionally one or moremerchant transaction processing requests; and, using the same or anothernetwork communication system 138, route the select merchant tokenconfirmation request to a payment authorization management system 120.Such optional merchant transaction processing requests can, for example,include data representing requests that a discount to be applied to oneor more price terms associated with transaction request data setsgenerated by one or more designated purchaser communication devices;and/or new, special, or modified a loyalty account points award rules tobe applied with respect to transactions associated with transactionrequest data sets generated by one or more designated purchasercommunication devices.

Moreover, in the same and other aspects and embodiments, the inventionprovides purchaser communication devices 110, wherein such a devicecomprises one or more one data communication systems 612, 614, one ormore data processors 602, one or more of input, output, and input-outputdevices 610, 621, 623, 625, 627, 629, etc.; and one or more persistentmemory devices 606, 604, 618, the at least one persistent memory device606, 604, 608 comprising stored, machine-interpretable instructionsrepresenting a merchant transaction management application 114 andadapted to cause the at least one data processor 602 to control thegeneration, receipt, and processing of data, routing of data using theat least one data communication system, and access to secure persistentmemory 618, in accordance with one or more logical structures associatedtherewith. The same or another persistent memory device(s) 606, 604, 618of the purchaser communication device 110 can comprise stored,machine-interpretable instructions representing a payment managementapplication 112 and adapted to cause the same or another at least onedata processor 602 to control the generation, receipt, and processing ofdata, routing of data using the same or another at least one datacommunication system, and access to the same or other secure persistentmemory in accordance with one or more logical structures associated withthe application 114, separately from the application 112. The at leastone processor 602 can further be configured to, in accordance withlogical structures associated with the merchant transaction application114, receive from at least one input device 610 signals representing acommand to designate one or more payment source accounts to be used infunding transactions conducted with at least one select merchant 130; inaccordance with logical structures associated with the paymentmanagement application 112, route to at least one payment authorizationmanagement system 120 an eligible accounts list request data set, theeligible accounts list request data set comprising data representing atleast one or more purchaser identifiers; and receive from the at leastone payment authorization management system 120 an eligible accountslist data set, the eligible accounts list data set comprising datarepresenting at least one or more identifiers associated with each ofone or more payment source accounts eligible for use in funding purchasetransactions. The at least one processor 602 can further be configuredto, for example, generate and display on an output device 610 asuitably-configured GUI 640 for use by the user 190, and thereafterreceive from at least one input device 610, in response to selectionsmade by the user 190, signals representing a designation of at least oneof the one or more payment source accounts eligible for use in fundingpurchase transactions, and route to at the least one paymentauthorization management system 120 a select merchant payment tokenrequest data set comprising data representing at least identifiersassociated with the one or more designated payment source accounts to beused to fund transactions conducted with at the least one selectmerchant 130. Moreover, in accordance with logical structures associatedwith the payment management application 112, the at least one processor602 can be configured to receive from the payment authorizationmanagement system 120, via the same or another data communication system612, 614, a select merchant payment token; and in accordance withlogical structures associated with the merchant transaction application114, route the select merchant payment token to at least one merchanttransaction management system 130 associated with the merchanttransaction application 114, using the same or another datacommunication system 610, 612.

Among the many advantages offered by the various aspects and embodimentsof the invention is increased security, because bank and other fundingsource account numbers, which are in some circumstances subject tofraudulent misuse, need not be communicated between devices 120, 130,110 at all; rather proxy identifiers such as “my checking account” or“my Merchant rewards account” can be exchanged, and mapped into actualrouting and account information by the responsible payment authorizationmanagement system 120. And when such numbers or other sensitiveinformation needs to be communicated, it can be communicated solelythrough applications 112 generated by the FI system 120 itself, so thatcontrol over security is not lost. Thereafter, secure select merchanttokens can take the place of any one or more account numbers or otheridentifiers required for processing of payments and settlement oftransactions.

Moreover, using systems and processes as described above, FI's 120,purchasers 190, and optionally merchants 130 can agree on paymentfunding sources without any need for the merchant 130 to know thefunding sources, or even the type(s) of funding sources involved. Inaddition, merchants and purchasers need not agree on payment protocolsto be used, so long as either or both can communicate with the FI system120.

To initiate a transaction using one or more select merchant tokensgenerated according to the foregoing, a user 190 may invoke a merchantapplication 114 on a device 110 and select one or more items (goodand/or services) to be purchased, rented, leased, etc. For example, uponaccessing a merchant application 114 the user 190 can use anysuitably-configured keyboards, keypads, pointers, touch screen devices,and/or other input/output device(s) 610 in conjunction withsuitably-configured user interface display screens to designate suchgoods or services. As part of a checkout sequence, merchant application114 may transmit (directly or via any other suitable components, such asmPOS or POS device(s) 132, 134) a request to merchant backend 136 arequest for confirmation of purchase terms and other details, includingfor example price(s), quantities, goods/services to be purchased,date/time of delivery, location of delivery or pickup, etc.

Alternatively, a user may initiate a transaction from within any otherapplication or program 112, 116, etc. by selecting a suitable start-upcommand item 112, 116, etc. As part of a checkout sequence, for example,a user can use any suitably-configured I/O devices 610, in conjunctionwith suitably-configured user interface I/O display screens, to select awallet application 112 for payment. Such selection may be in response topresentation of multiple different payment options, including thosewhich do not use a wallet application 112.

An example process 2500 for use of an select merchant payment tokengenerated in accordance with process 2400 shown in FIG. 3 in order tocomplete a payment transaction is shown in FIG. 4 .

Process 2500 can begin at 2502, when a user 190 accesses a merchantapplication 114 online, or at a merchant POS 132, 134, or uses a generalinternet browser to access a merchant online e-commerce applicationhosted by a merchant system 136, to negotiate a purchase transaction.

At 2504, for example, a user of a merchant application 114 associatedwith a merchant “My Store” as described above who has used one or moreGUIs generated by the merchant application 114 to identify one or moreitems for purchase can be presented with a GUI 650 such as that shown inFIG. 8 , comprising a list 652 of items to be purchased, a list 654 ofprices associated with the items to be purchased; a total purchase price656 (including any applicable taxes, etc.) to be paid, and one or morecommand items 658, 660 associated with payment options.

Selection of command item 660 “My Wallet” can cause processor(s) 602 ofthe user's device to invoke a virtual wallet application 112, andprocess payment in accordance with logical structures associated withthe application 112. Such processes can, for example, result ingeneration of a transaction request data set, and routing of such dataset to an FI system 120 associated with the virtual wallet 112 forprocessing and payment using one or more accounts designated through thevirtual wallet application 112. In such a case the user 190 can becharged, and pay, the full purchase price 656 shown in FIG. 8 .

Alternatively, selection command item 658 “Token Pay” can causeprocessor(s) 602 of the user's device to generate and at 2505 route to acorresponding a merchant POS system 132, 134, a merchant backend system130, 136, an select merchant payment token transaction request data setcomprising an select merchant payment token generated in accordance withprocess(es) 2400 described above. Such an select merchant payment tokentransaction request data set can, for example, be formatted according toany desired payment protocol, and can comprise:

-   -   <address of secure FI portal><originating (user return) network        address>        -   <select merchant payment token><purchase price>            where:    -   <address of secure FI portal>=network resource locator        associated with responsible payment authorization management        system 120    -   <originating (user return) network address>=network resource        locator(s) to which confirmations and/or other communications        are to be returned    -   <select merchant payment token>=unpredictable character set(s)        or other credentials uniquely associated with the merchant(s)        associated with the request and accounts to be used as sources        of payment funds, as described in connection with process 2400        above    -   <purchase price>=nominal purchase price to be paid for the        transaction, as shown for example at 656 in FIG. 8 and paid by a        user who elects payment through a virtual wallet application        112.

At 2506, a network communication system of the merchant backend system130, 136 can forward the select merchant payment token transactionrequest data set to the secure FI portal address, optionally (as shownat 2506) via conventional transaction processing systems (payment rails)150.

Alternatively, at 2504-2508 the select merchant payment tokentransaction request data set can be forwarded directly to the secure FIportal address by the merchant API of the user's device 110, using oneor more short-range or network communications systems 612, 614, withoutmaking use of either a merchant backend system 136 or payment rails 150.

At 2508-2510 the payment authorization management system 120 to whichthe transaction request data set has been routed can parse andadjudicate the request. For example, by interpreting the select merchantpayment token included in the data set and using it, by means oftable-look or other processes in a suitably-configured data base ofselect merchant payment token data sets, the FI system 120 can identifythe corresponding authorized merchant data set and confirm the existenceand validity of the data set, availability of funds in identified sourceaccounts, etc., permissibility under applicable laws, regulations, andrules etc.

Moreover, at 2508 the payment authorization management system 120 canidentify and apply and special transaction requests designated by themerchant 130 or other parties. For example, where a merchant 130 hasrequested application of one or more discount, rebate, or loyalty awardsrules, the FI system 120 can confirm the propriety of their applicationto the current request. Accordingly, for example, the system 120 candetermine that a discount is to be applied, and calculate a reduced orotherwise adjusted price to be applied to the transaction.

At 2510 the payment authorization management system can confirm theavailability of adequate funds, rewards points, etc., to satisfy thetransaction request. This process can, for example, involve applicationof split-pay processes described above, communications with third-partyrewards administrators 160, etc., and conversion (or request forconversion) of loyalty or other rewards points to equivalent cash value,conversion of foreign currencies, etc.

Conditioned upon availability of adequate funding resources, at 2511 thepayment authorization management system 120 can approve the request, anddebit or otherwise update funding source accounts to settle thetransaction. This can for example include notifying third-party credit,loyalty, rewards program administrators, etc., of the transaction andapproval of the application of resources associated with such accountstoward the transaction. As will be understood by those skilled in therelevant arts, such transaction settlement procedures can proceed inreal time, or periodically (e.g., end of day or business week) inaccordance with a wide variety of accepted or otherwise-desiredprocesses or conventions.

As shown in FIG. 4 , token management processes and account crediting,debiting, and other updating/administrative procedures can beimplemented by a single FI system 120, or can be divided along anydesired or required lines. For example, storage, parsing, andmaintenance of records pertaining to select merchant payment tokens canbe handled by specialized or otherwise separate token managementservices 160, while account administration procedures can be handled byseparate FI(s) 120.

In embodiments where an FI system 120, 160 applies special transactionprocessing requests such as discounts, rebates, or special loyaltypoints awards, at 2512 the system 120, 160 can generate a purchasertransaction approval data set, and route it directly or indirectly tothe requesting merchant application 114. Such a purchaser transactionapproval data set can, for example, include:

-   -   <originating (user return) network address>        -   <final transaction terms>            where:    -   <originating (user return) network address>=network resource        locator(s) to which confirmations and/or other communications        are to be routed    -   <final transaction terms>=data representing authorized and        optionally updated transaction terms, including discounted or        otherwise updated price(s), proposed loyalty points awards, etc.

On receipt of a purchaser transaction approval data set, logicalstructures associated with a merchant application 114 or walletapplication 112 can cause processor(s) 302 to generate and display apurchaser approval GUI such as purchaser approval GUI 670 shown in FIG.9 , which includes item list 652, original price terms 654, updated (inthis case, discounted) price terms 664, and updated total price 668.Upon satisfactory review and approval of the proposed revisedtransaction terms, a user 190 can use a command item 672 to generate apurchaser select merchant transaction confirmation data set, which caninclude a simply yes/no flag, and route the approval to the purchaseauthorization management system 120. Upon receipt, the system 120 canprocess any final transaction approvals, account balance updates, etc.

Among the advantages offered by such embodiments of the invention is theability of a user 190 to decline alternative transaction terms,including discounted prices or modified loyalty wards applications, atany time prior to completion of the purchase (e.g., by selecting commanditem 672). For example, a user 190 not wishing to accept such modifiedterms can generate a select merchant offer decline command by selectinga command item 671 “No Thanks” and reverting to terms shown, forexample, in GUI 650 of FIG. 8 . Alternatively, such a user can avoidconsideration of alternative terms altogether by selection of a commanditem 660 “My Wallet” in a GUI 650, so as to complete transactionexecution by, for example, invoiding another payment managementapplication 112.

With a transaction request successfully adjudicated and approved by FIsystem(s) 120, 160, at 2513-2514 a,b,c the system(s) 120, 160 cangenerate a suitably-formatted transaction confirmation data set androute it to any one or more of merchant backend system(s) 130, 136, POSs132, 134, and/or merchant application(s) 114. As shown in FIG. 4 , suchconfirmations may be routed over conventional payment rails 150.

Thus it may be seen that in various aspects and embodiments theinvention provides networked payment authorization management systemsaccording to the foregoing, configured such that at least one dataprocessor 122 can receive from at least one of a purchaser communicationdevice 110 and a merchant transaction management system 130, using atleast one network communication system, a transaction request data set,the transaction data set comprising data representing at least theselect merchant payment token and a transaction price, and optionallyone or more merchant transaction processing request. In such aspects andembodiments, such select merchant payment tokens can be subject to oneor more account eligibility restrictions imposed by the paymentauthorization management system 120, which may for example be legal,regulatory, or commercial in nature.

The invention further provides, in the same and further aspects andembodiments, networked merchant transaction management systems, such asystem comprising processor(s) 137 adapted to receive from purchasercommunication devices 110, via one or more one network communicationsystems 138, merchant transaction processing request confirmation datasets, the merchant transaction processing confirmation data setcomprising data representing confirmation of acceptance by a paymentauthorization management system 120 of one or more merchant transactionprocessing requests.

It may further be seen from the foregoing that the invention providespurchaser communication devices adapted to receive from merchanttransaction management systems 130, using one or more datacommunications systems 612, 614, data representing goods or services tobe purchased from one or more merchants associated with the systems 130,and corresponding price terms; to generate transaction request datasets, such a set comprising data representing at least a select merchantpayment token associated with the merchant and a transaction priceassociated with the corresponding price terms; and, using the same oranother data communication system 612, 614, route the transactionrequest data set to at least one of the merchant transaction managementsystem 130, 132, 134, 136 and one or more payment authorizationmanagement systems 120.

As a further example, at 2504 in FIG. 4 the merchant application 114 canaccess and route to a POS system 132, 134 and/or a merchant system 130 aselect merchant payment token returned to the corresponding merchantsystem 130 at 2422, such token having been stored on the user's device110, or accessed via the merchant backend system 136, etc. Theauthorized merchant payment token may be used to generate a transactionauthorization request data set as described above, the transactionauthorization request data set comprising fields as described above,including a payment type identifier associated with a payment typeand/or protocol preferred by the merchant and one or more identifiersassociated with funding sources preferred by the user 190. By using aformat of the type described above, for example, a discretionary fieldcan be used to identify one or more funding sources preferred by theuser.

At 2506, the merchant system 130, 132, 134 can route the transactionauthorization request data set generated at 2504 to the FI system(s)120, 160 associated with the preferred funding source(s) designated bythe user in process 2400. By using processes and formats describedabove, the transaction authorization request data set can be routed over‘conventional’ payment network rails 150, and at 2508 interpreted andotherwise processed by components 150 like any other payment request.

At 2508-2514, the requested transaction may be processed and adjudicatedin accordance with suitable process(es), including those describedabove, including for example by checking at 2510 for the availability ofadequate funds/points balances in preferred funding source(s) identifiedby the user 190 and routing approvals at 2512, 2514. Such processes can,for example, include the use of split pay and/or real-time creditprocesses such as those described.

Merchant authorization and/or application payment tokens in accordancewith the invention can be configured to enable the merchant to requestthat an FI 120 to which the token is routed to perform any of a verywide range of business functions, in addition to or in lieu of paymenttransactions. For example, through the use of discretionary data fieldsin accordance with existing or ‘conventional’ payment protocols, orthrough the use of specifically-formatted tokens in accordance with theforegoing, the application or award of unique rewards functions, paymentrefunds, etc., can be executed in accordance within instructions of thecorresponding merchant system 130.

Among the many advantages offered by systems and process in accordancewith the invention is their provide to adapt to developing technologies.For example, systems and processes in accordance with the invention,combined with suitable security features, may be implemented wholly orpartly through the use of various forms of public ledgers, such asblockchains. For example, in some embodiments one or more mPOSs or othertrusted devices 110′ may be established as a node in a blockchain ledgersystem. In such an implementation, each trusted device 110′, includingany trusted mPOSs 134, may route transaction data sets securely frommerchant system(s) 130 to FSP systems 160, 120 while complying withapplicable blockchain/public ledger protocols.

As will be appreciated by those skilled in the relevant arts, a blockchain is a distributed and generally encrypted or otherwise secure datastore that acts as a virtual public ledger of transactions, and isparticularly useful in implementing cryptocurrencies such as bitcoin. Insuch ledger schemes a plurality of devices are implemented as node, eachnode controlling or otherwise having access to a distinct, complete orpartial stored copy of the ledger; the ledger comprises data setsrepresenting legal or otherwise recognized tender for transactions. As atransaction progresses, each involved network node can validate thetransaction, or a portion of it, and generate data representing suitableledger annotations, enter the annotations in the node's portion or copyof the ledger, and push or make available updated ledger annotations toother nodes.

The foregoing description is intended to provide a thorough descriptionof various aspects and example embodiments of one or more inventions.Accordingly, various aspects and/or components of such invention(s), andspecific exemplary combinations thereof, have been described throughoutat multiple different levels of abstraction. In some instances,embodiments may have been described on both a specific and a relativelygeneral or generic level, for example, where an aspect or component ofthe embodiment is susceptible to variation in a manner that is notinconsistent with the specific structure(s) and/or operation(s) setforth. In these instances, the specific embodiments set forth herein maynot be the only ones contemplated and instead may only be exemplary of amore general or generic configuration. The scope of the invention(s)described herein is therefore defined solely by the language of theclaims appended hereto, giving due consideration to applicable doctrinesfor construing their meaning.

Moreover, as will be appreciated by those skilled in the relevant arts,a very wide variety of payment systems and transaction processes areenabled by the invention. While various specific combinations andembodiments have been described, it is very much contemplated that theymay be used together in a very wide variety of combinations, even wherespecific combinations have not been described, due to practical concernsfor brevity and clarity. As a specific example, the various processesdisclosed and otherwise suggested or described can in many instances beimplemented in orders or sequences other than those discussed inconnection with exemplary embodiments.

It is intended that all such variations which are consistent scope ofthe claims presented herein are within the scope of the invention.

1. A networked merchant transaction management system comprising: atleast one network communication system; at least one data processor; andat least one persistent memory device, the at least one persistentmemory device comprising stored, machine-interpretable instructionsadapted to cause the at least one data processor to: receive from apurchaser communication device, using the at least one networkcommunication system, a select merchant payment token request data set,the select merchant payment token request data set comprising at leastone secure purchaser identifier and a secure select merchant paymenttoken; generate a select merchant token confirmation request, the selectmerchant token confirmation request comprising data representing atleast the secure select merchant payment token; using the same oranother network communication system, route the select merchant tokenconfirmation request to a payment authorization management system. 2.The networked merchant transaction management system of claim 1, whereinthe select merchant token confirmation data set comprises datarepresenting at least one merchant transaction processing request. 3.The networked merchant transaction management system of claim 2, whereinthe data representing the at least one merchant transaction processingrequest comprises data representing a discount to be applied to one ormore price terms associated with transaction request data sets generatedby one or more designated purchaser communication devices.
 4. Thenetworked merchant transaction management system of claim 2, wherein thedata representing the at least one merchant transaction processingrequest comprises data representing a loyalty account points award ruleapplied with respect to transactions associated with transaction requestdata sets generated by one or more designated purchaser communicationdevices.
 5. The networked merchant transaction management system ofclaim 4, wherein the machine-interpretable instructions are adapted tocause the at least one data processor to receive from a purchasercommunication device, using the at least one network communicationsystem, a merchant transaction processing request confirmation data set,the merchant transaction processing request confirmation data setcomprising data representing confirmation of acceptance by a paymentauthorization management system of one or more merchant transactionprocessing requests.
 6. The networked merchant transaction managementsystem of claim 1, wherein the select merchant payment token requestdata set further comprises: one or more purchaser-selected merchantidentifiers; and one or more purchaser-selected payment sourceidentifiers.
 7. The networked merchant transaction management system ofclaim 6, wherein the select merchant token confirmation request furthercomprises: one or more merchant-selected purchaser identifiers; and oneor more merchant-selected protocols associated with the one or morepurchaser-selected payment source identifiers.
 8. The networked merchanttransaction management system of claim 6, wherein the secure selectmerchant payment token is associated with associated with the one ormore purchaser-selected merchant identifiers.
 9. The networked merchanttransaction management system of claim 6, wherein the secure selectmerchant payment token is associated with the one or morepurchaser-selected payment source identifiers.
 10. A purchasercommunication device comprising: at least one data communication system;at least one data processor; one or more of input, output, andinput-output devices; at least one persistent memory device storingmachine-interpretable instructions representing a merchant transactionmanagement application and adapted to cause the at least one dataprocessor to control the generation, receipt, and processing of data,routing of data using the at least one data communication system, andaccess to secure persistent memory in accordance with one or morelogical structures associated therewith; the same or another least onepersistent memory device of the purchaser communication devicecomprising stored, machine-interpretable instructions representing apayment management application and adapted to cause the same or anotherat least one data processor to control the generation, receipt, andprocessing of data, routing of data using the same or another at leastone data communication system, and access to the same or other securepersistent memory in accordance with one or more logical structuresassociated therewith; wherein the at least one processor is configuredto: in accordance with logical structures associated with the merchanttransaction application, receive from at least one input device signalsrepresenting a command to designate one or more payment source accountsto be used in funding transactions conducted with at least one selectmerchant; in accordance with logical structures associated with thepayment management application: route to at least one paymentauthorization management system an eligible accounts list request dataset, the eligible accounts list request data set comprising datarepresenting at least one secure purchaser identifier; and receive fromthe at least one payment authorization management system, an eligibleaccounts list data set, the eligible accounts list data set comprisingdata representing at least one or more identifiers associated with eachof one or more payment source accounts eligible for use in fundingpurchase transactions; receive from at least one input device signalsrepresenting a designation of at least one of the one or more paymentsource accounts eligible for use in funding purchase transactions; routeto at the least one payment authorization management system a selectmerchant payment token request data set, the select merchant paymenttoken request data set comprising data representing at least identifiersassociated with the one or more designated payment source accounts to beused to fund transactions conducted with at the least one selectmerchant; in accordance with logical structures associated with thepayment management application, receive from the payment authorizationmanagement system, via the same or another data communication system, aselect merchant payment token; and in accordance with logical structuresassociated with the merchant transaction application, route the selectmerchant payment token to at least one merchant transaction managementsystem associated with the merchant transaction application, using thesame or another data communication system.
 11. The purchasercommunication device of claim 10, the machine-interpretable instructionsadapted to further cause the at least one data processor, in accordancewith logical structures associated with at least one of the merchanttransaction application and the payment management application, to:receive from the merchant transaction management system, using the atleast one data communications system, data representing one or moregoods or services to be purchased, and corresponding price terms;generate a transaction request data set, the transaction request dataset comprising data representing at least the select merchant paymenttoken and a transaction price associated with the corresponding priceterms; and using the same or another data communication system, routethe transaction request data set to at least one of the merchanttransaction management system and the payment authorization managementsystem.